MSC4319: Room member events for invite and knock rooms in the /sync response - #4319

This equally applies to the new state with full events as well. The invite membership event is not "validated" (checked to pass auth rules).

Related reading on outliers and out-of-band membership events in the Synapse docs.

This doesn't say that the event that we place in state was validated though. It just explains why we should avoid as much as possible to provide the full event format.

Maybe this should be clarified in the spec PR for this MSC?

Using full state event in state has the same drawbacks of using the full state events in invite_room_state.

I'm not seeing the benefit of the complexity around having both state and invite_room_state (which will be hard to understand from a newcomers perspective) when we could just use full events in invite_room_state with some better notes in the spec.

Yeah, this introduces additional complexity, that doesn't seem that beneficial. It would be much easier and more backwards compatible to simply have those events in the invite_state as before.

The original concern of this thread regarding validation of events has a long and storied history. The conclusion is validation isn't needed right now because the data remains untrusted by nature. If/when a future MSC includes the full recursive auth chain, then servers can verify the invite.

For the concern of having two fields doing different things: another MSC to deprecate [invite|knock]_state is welcome. This MSC would not be the one to make that change. If that future MSC were to move quickly enough through the process, I'd suggest that the spec PR for this MSC and that future MSC incorporate both changes (potentially delaying this MSC's merge date).

I feel like this MSC should solely propose this change on its own: Include the m.room.member for the invite/knock event itself AND m.room.member event for the sender of the invite in stripped state.

All of the extra complexity around clients wanting access to event_id, origin_server_ts, or even full state events is a separate topic. I don't believe the complexity around state vs invite_state is a great approach.

The purpose of this MSC is to specify behavior that has already been implemented for a long time in some homeservers and clients while not being part of the spec.

It turns out that the current implementations rely on an undesirable API (like mixing event formats) so the extra complexity is needed to have a more consistent API at the cost of requiring changes in implementations.

I don't believe that wanting to access the extra fields is a separate topic because it is all about clients having enough data to present/handle invites and knocks. Without the extra fields, the m.room.member for the invite/knock event itself isn't very useful because it doesn't really provide more data (we can already infer the membership).

The stripped state version does provide value: The invite is useful to see the invite reason and sender and including the m.room.member of the sender gives you access to the display name/avatar of the person that invited you.

I would consider the current Synapse behavior flawed and including the full state event probably was a simple oversight (element-hq/synapse@ab9cf73).

The only examples of clients that use this extra information are progressive enhancement examples. We can equally instead fix the spec and the Synapse implementation to do the right thing without the clients losing much at all for spec-compliant homeservers. The desire for more info is valid and can be separately advanced in its own MSC that adds the necessary metadata (whatever solution that may be).

The SCT has previously expressed interest in consistency: either return full state events, or don't. There should not be a mix of formats. The SCT has also expressed that continuing to call it "stripped state" when it contains fully formatted events is wrong. There's also mild opinions around naming it specifically "[invite|knock]_state" when it's the same thing regardless of membership type - it doesn't need to be overly qualified.

These considerations are mentioned somewhere in the depths of #4311, alongside other arguments not relevant to this proposal.

Whether the information is valuable or not is somewhat irrelevant - the format should be consistent, and getting the information needed from an m.room.member event means it's best formatted as a real event. Therefore, all previously-stripped state events should be formatted as real events too.

It is valuable to confirm that this half-baked state that this MSC ships is not great.

I still think this MSC should have simply defined the extra m.room.member events in stripped state and then another MSC would propose returning full state events for the further use cases.

It sounds like the way forward now that this MSC is merged is to just define that all stripped state events should be presented as full state events in state. Based on #4319 (comment), perhaps even deprecating invite_state/knock_state

That would be my preferred direction, as an individual.

Introducing m.room.member as stripped state provides none of the useful information to clients while the full event does. We are currently opposed to mixing formats within the same structure, so a new field is required.

Introducing m.room.member as stripped state provides none of the useful information to clients

(it does, see "The stripped state version does provide value:" above)

There are other use cases it doesn't cover but those are the things to be covered by the further MSC.

What other clients have relied on the full state of the invite/knock being available?

The only example given so far has been Draupnir wanting event_id.

In the description of the PR there are a couple of clients accessing the origin_server_ts.

This seems like much too short of a timeline. I think quite a few clients rely on this event being in the invite_state, even if it is stripped. Removing that after 3 months, when until then clients couldn't rely on it being elsewhere and breaking every client someone might have gotten from a distro repo like Ubuntu, is a bit problematic. But I guess servers will have to support it in both places for longer, if they support an old spec version?

The version of the spec matters less here. The timeline is probably a bit short, but as a SHOULD there's room for servers to make the best decision for their local ecosystems. Some servers may be able to move faster, some slower - this MSC sets a guideline for what to aim for.